pp108 : Configuring ACL for Database Metadata

Configuring ACL for Database Metadata

This topic describes the procedure to configure an ACL for the database metadata.

Before you begin this task:
You must have the role of WS-AppServer Administrator to perform this task.


This feature provides Administrators an option at run time to set or modify ACLs on the database metadata objects such as tables, views, and procedures. For tables and views, you can set access control at various levels -Read,Insert,Update, andDelete. For procedures, you can set only one type of access control calledAllow.

You also have the option to set Conditional ACL on each metadata object (applicable only to Tables and Views). This option also provides the Administrators a facility to override the ACL set on the Database Metadata while developing the application.

  1. On CUSP > My Applications , click (Database Metadata Manager). The Database Metadata Manager window appears, displaying the Metadata Explorer and the contents of the configured WS-AppServer Service.
  2. Expand the contents of the WS-AppServer Service until you see (Tables) , (Procedures), and (Views) and their contents.
  3. Depending upon your requirement, right-click a Table or a Column, or a View, or a Procedure and select Security. The Security App Palette appears to the right of the Metadata Explorer, displaying the name of the selected metadata object on which you can set permissions (Read, Update, Insert, Delete) for users or roles.
  4. On the Security AppPalette, click Add to select the user or role for whom you want to set the ACL. The Organizational Users/Roles - Users/Roles dialog box appears with a list of Names, along with the Type and Description for each user or role.
  5. Select a user or role and click the OK. The selected user or role appears on the Security App Palette with permission granted by default for all levels - Read, Update, Insert, and Delete (you see a tick mark for each level). For procedures, you see a tick mark under Allow.
    Note: For tables and views, the permission is hierarchical in nature, Read being the lowest level of permission and Delete being the highest level. So, if you deny Read permission, the denial also applies to the remaining levels, and if you permit Delete, you grant permission to all the levels.
  6. Do one of the following:
    • Depending upon the level of access you want the particular user or role to have on the selected metadata object, select or clear the check box for a permission type.
    • You can set Conditional ACLon the metadata object (only tables or views) for the selected user or role. To switch to Conditional ACL, do the following:
      1. Select the Conditioncheck box. A confirmation message:
        "You are moving to Conditional mode ACL.
        The existing ACL will not be retained when changing the mode. 
        Are you sure you want to proceed?"

        appears.

      2. Click Yes on the message box. The message box closes and the RUID button (stands for Read, Update, Insert, Delete) appears next to the Condition check box.
      3. Click RUID. The Conditional ACL dialog box appears.
      4. Select an Allow condition (Read, Update, Insert, Delete) from the options, provide the condition content in the text area and click OK. The Conditional ACL dialog box closes and the RUID highlights one of the alphabets in red indicating the selection. For instance, if you selected Read, R is shown in red.
  7. Click Apply followed by OK to save the changes. The permission level on that metadata object is defined for the selected user or role.

    You have configured the ACL for the selected database metadata.

Related concepts

Conditional ACL

Related tasks

Configuring ACL for Web Service Interfaces and Operations
Configuring ACL for Service Groups
Configuring ACL for LDAP Objects
Configuring ACL for XMLStore Objects
Configuring ACL for Roles
Configuring ACL for Users

Related reference

Unconditional ACL
ACL Parameters
ACL Definitions
ACL Explorer Interface